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REMARKS 

Claims 1-23 arc pending in the current Application. No Amendments to the claims are 
being made herein. 

Applicants respectfully submit that claims 1-23 are patentable under 35 U.S.C. 103(a) 
over Macon et a]. (US 5410653) in view of Hussain ct al. (US 6901500). With Tespect to claim 
1, Applicants submit that neither Macon, Hussain, nor their combination, teach or suggest each 
and every element of claim L For example, claim 1 includes a first prefetch limit which controls 
how many prefetches occur between misses in the prefetch buffer. Applicants submit that at 
least this is not taught or suggested by the cited references. The Examiner cites FIG. 6 of Macon 
and column 5, lines 45-65, and states that Lmax teaches the first prefetch limit. However, 
Applicants respectfully disagree. Firstly, Lmax is simply a max value for L, where L indicates 
how many contiguous data blocks are to be fetched during a subsequent prefetch. When a hit 
occurs in Ihe MRRS, L is incremented (in block E) because the likelihood that a hit will occur 
again in the contiguous blocks is increased, and thus more data blocks can be prefetched during a 
next prefetch operation (in block G). When a miss occurs, though, L is decremented (in block 
M) because the likelihood that a hit will occur decreases. However, even if L reaches Lmax, and 
is held at Lmax, a prefetch of Lmax units (in block G) can continue to occur upon hits in the 
MRRS. L thus does not limit a number of prefetches which occurs between misses because any 
number of prefetches can occur between misses in Macon. For example, the prefetch of L units 
(even if L=Lmax) in block G in FIG. 6 can occur any number of times between misses. That is, 
so long as hits in the MRRS continue, a prefetch can be performed at block G. Referring to FIG. 
4 of Macon, note that L does not limit the number of prefetches (e.g. PF1, PF2, PF3, etc.) which 
can occur between misses, but only indicates how many blocks (1, 2, 3, or 4) are to be prefetched 
during each prefetch (e.g. PF1, PF2, PF3, etc.). Furthermore, there is never a point in Macon 
where, based on the value of L, prefetches are no longer allowed upon a hit because L does not 
provide a prefetch limit as claimed. Hussain also does not teach or suggest the prefetch limit of 
claim 1 , and therefore, Applicants submit that for at least these reasons, claim 1 is allowable over 
the cited references. 
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Claims 2-9 are not being independently addressed because they depend directly or 
indirectly fi-om allowable claim 1 and are therefore allowable for at least those reasons provided 
above with respect to claim 1. 

With respect to claim 10, claim 10 includes using a prefetch limit to limit a number of 
prefetches performed between misses in a prefetch buffer. Applicants submit that at least this is 
not taught or suggested by the cited references. The reasons provided above with respect to 
claim 1 also apply here to claim 10. Therefore, for at least these reasons, Applicants submit that 
claim 10 is allowable over the cited references. 

Claims 11-14 are not being independently addressed because they depend directly or 
indirectly from allowable claim 10 and are therefore allowable for at least those reasons which 
apply to claim 10. 

With respect lo claim 15, claim 15 includes if a read request results in a hit, selectively 
performing a prefetch . . . based at least in part on a prefetch counter reaching a first value. 
Applicants submit thai at least this is not taught or suggested by the cited references. For 
example, the Examiner indicates that the prefetch counter is taught by the use of L in Macon. 
However, note that in Macon, prefetching is not selectively performed upon a hit based on the 
value of L. That is, as described above, L docs not affect whether or not a prefetch occurs in 
block G. Assuming that it is the first MRRS hit in diamond F, a prefetch does in fact occur 
regardless of the value of L, and does not selectively occur based on L reaching a particular 
value. L simply indicates how many data units are to be prefetched for the prefetch in block G. 
Furthermore, note that Macon does not teach or even suggest a prefetch counter, in that no 
counter in Macon counts the number of prefetches (e.g. PF1, PF2, PF3, etc.) which occur. 
Hussain also does not teach or suggest the prefetch counter and selectively prefetching as 
claimed. Therefore, for at least these reasons, Applicants submit that claim 15 is allowable over 
the cited references. 

Claims 16-23 depend directly or indirectly from allowable claim 15, and are therefore 
also allowable for at least those reasons provided with respect to claim 15. 

With respect to claim 20, Applicants also submit that Macon at least does not teach or 
suggest not pre/etching from the storage circuitry when the read request results in a hit and the 
prefetch counter has reached a first value. That is, the only case in which, in Macon, a prefetch 
does not occur upon a hit is if it is not the I st MRRS hit (in diamond F). However, L reaching a 
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particular value (or a coumer reaching the value of L) does not result in no prefetching upon a 
hit. The Examiner proceeds to state that the value of the counter is used to fetch L data blocks 
and therefore prefetching activity will stop when it reaches its values. However, as discussed 
above, L provides the number of blocks to be fetched during a particular preFetch, but a counter 
counting to the value of L does not actually prevent a prefetch from occurring as claimed in 
claim 20. Therefore, for at least these additional reasons, Applicants submit claim 20 is 
allowable over the cited references. 
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Conclusion 



Although Applicants may disagree with statements made by the Examiner in reference to 
the claims and the cited references, Applicants are not discussing all these statements in the 
current Office Action, yet reserve the right to address them at a later lime if necessary. 

Applicants respectfully solicit allowance of the pending claims- Contact me if there are 
any issues regarding this communication or the current Application. 

If Applicant has overlooked any additional fees, or if any overpayment has been made, 
the Commissioner is hereby authorized to credit or debit Deposit Account 503079, Freescale 
Semiconductor, Inc. 



Respectfully submitted, 



Freescale Semiconductor, Inc. 
Law Department 



SEND CORRESPONDENCE TO: 



By: 




Customer Number: 23125 



Attorney of Record 
Reg. No.: 43,629 
Telephone: (512) 996-6839 
Fax No.: (512) 996-6854 
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